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Description 

BACKGROUND OF THE INVENTION 

This invention relates generally to systems for pro- 
viding graphics environments for application programs, 
and more particularly to common window management 
interfaces for systems capable of running multiple ap- 
plication programs written for various environments. 

In modern data processing, protocols allow applica- 
tion programs to communicate with system components 
such as I/O devices or servers. These protocols include 
application programming interfaces, interprocess com- 
munication protocols, and remote procedure calls. With 
the rapid growth of computers and application pro- 
grams, there has been a parallel growth in the number 
of software and hardware protocols. The existence of 
multiple protocols throughout the data processing in- 
dustry has been a source of inconvenience because ap- 
plication programs written for one protocol must be mod- 
ified, rewritten, or even redesigned, for a different pro- 
tocol. 

The problem of multiple protocols is particularly 
acute in the graphics area where there are a number of 
standards in use. Certain graphics systems use a soft- 
ware package called a display server to implement a 
graphics protocol. In such systems, application pro- 
grams requesting graphics services, called clients, send 
their graphics requests to the display server. 

The graphic services can include window manage- 
ment. Windows are areas on a video screen that allow 
a user to view data processing output. Windows also 
give application programs an organized way of manag- 
ing the use of space on the screen, and allow the display 
server to present information for multiple application 
programs in an organized way. If clients want windows, 
another software package called a "window manager" 
is generally used to control certain window management 
functions. 

By using a window manager, individual clients need 
not be concerned with window management functions, 
such as the positioning and sizing of windows. An ex- 
ample of a graphics system having a window manager 
common to a number of clients is one defined by the X 
Window System protocol, a standard developed at the 
Massachusetts Institute of Technology. Fig. 1 shows an 
X Window system, where client 110,1 20, and 1 30 send 
graphics request to X display server 140, thereby com- 
municating with graphics hardware 150. Client 130 is a 
window manager that can provide window management 
functions to both clients 110 and 120. 

Basic principles and architecture of the X Window 
System may be found in "Introduction to the X Window 
System" by Oliver Jones, Prentice-Hall 1989. The pro- 
tocol for communicating with an X Window display serv- 
er is described in "X Window System Protocol MIT X 
Consortium Standard X Version 11," Release 4, by Rob- 
ert W. Scheifler, MIT Laboratory for Computer Science. 



Conventions for communicating with the window man- 
ager, and with other clients, are described in "Inter-Cli- 
ent Communication Conventions Manual, Version 1.0, 
MIT X Consortium Standard," by David S.H. Rosenthal, 

5 Sun Microsystems, Inc. 

X Window Systems are not the only graphics sys- 
tems in use throughout the industry. Therefore, it may 
be necessary to execute clients written for an X Window 
System together with clients written for some other type 

70 of windowing system on a common set of graphics hard- 
ware. For purposes of the discussion that follows, the 
other type of windowing system will be referred to ge- 
nerically as a "host system." 

One proposal for providing window management 

15 functions for a data processing system running both cli- 
ents using the X Window System protocol ("X clients") 
and clients using the host system protocol ("host cli- 
ents") is shown in Fig. 2. Fig. 2 shows a unified window 
system 200 serving both X display server clients 210 

20 and 220 and host server clients 230, 240 and 250. A 
common window manager 260 is provided to present a 
uniform window interface to the user. An X server front 
end 270 implementing the X display server shares com- 
mon support functions 290 (conventions, code, data 

25 structures, hardware access structures, etc.) with a host 
server front end 280 implementing the host server, 
thereby allowing hardware resources to be harmonious- 
ly allocated. 

System 200, however, has several disadvantages. 

30 First it requires writing both an X display server front end 
and a host server front end. Second, it is not easy to 
build system 200 from existing host systems because 
of the many modifications required. 

Fig. 3 is an example of an existing host system 300 

35 which supports host system clients 310, 320, and 330. 
System 300 also includes a host server 340, including 
an internal window manager, to provide graphics func- 
tions to host system clients 310, 320 and 330. 

Converting system 300 of Fig. 3 into system 200 

40 shown in Fig. 2 presents both legal and technological 
problems. For example, the person attempting to imple- 
ment the X display server in system 300 might not pos- 
sess the legal right to modify the support technology 
used in the host server 340. Also, the support technol- 

45 ogy of the host server may be poorly documented or 
structured in such a way as to make it difficult or impos- 
sible to adapt to support another server. Therefore, it is 
desirable not to have to modify existing host systems. 
Fig. 4 shows another proposal to solve the X-server/ 

50 host system integration problem. In system 400 shown 
in Fig. 4, host clients 410, 420, and 430 of the host sys- 
tem are connected to a host server 440 that includes 
window management functions. Another host client 450 
is an X display server that operates by translating X pro- 

55 tocol to host protocol. X clients 460 and 470, which are 
written with the X protocol, are coupled to client 450 and 
thus can run using the graphics hardware 490 attached 
to host server 340 as host clients 41 0, 420 and 430 do. 
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In an X Window System, the common window man- 
ager is the window manager client. This window man- 
ager client is connected to the X display server, as are 
X clients. Clients send requests to the X display server 
to effect graphics operations. Certain requests sent from 
X clients to the X display server are redirected by the X 
display server to the window manager client. The win- 
dow manager client then processes the request, and 
may then send a request to the X display server. Other 
certain requests sent from X clients to the X display serv- 
er are processed by the X display server and notification 
is sent to the window manager client. 

When using the different types of clients in a single 
system as described above, it is desirable to present a 
user with a uniform user interface. One way to achieve 
this would be to tailor the window manager 480 of the X 
type system to have the window interface of the host 
system. One disadvantage of system 400 is that the 
process responsible for starting window manager 480 
would need to have knowledge of the type of host sys- 
tem in order to allow it to select a manager having the 
window interface of the host system. If the host system 
changes, a new window manager 480 is required. This 
is a problem because the process starting the window 
manager may exist on a network node separate from 
the host system, where it may be difficult to obtain 
knowledge of the type of host system. The separation 
of window manager 480 from X server 450 can make it 
difficult to track changes to the host system. 

SUMMARY AND OBJECTS OF THE INVENTION 

It is therefore an object of this invention to provide 
a display server that can be implemented using the sup- 
port technology of another server. 

It is a further object of this invention to allow clients 
written with various types of protocols to run together on 
one set of graphics hardware. 

It is still a further object of this invention for the win- 
dow management interface presented to the user to be 
consistent between clients written with the various pro- 
tocols. 

Briefly, this invention emulates a window manage- 
ment structure in a display server. This ensures that 
there will always be an appropriate window manager for 
the clients that will present a uniform window interface 
to the user. 

To achieve these and other objects of the present 
invention, there is provided a computer system and 
method as defined in the appended claims 1 0 and 1 re- 
spectively. 

The accompanying drawings, which are incorporat- 
ed in and which constitute a part of this specification, 
illustrate one embodiment of the invention and, together 
with the description, explain the principles of the inven- 
tion. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a diagram of a prior art X Window 
graphics system. 
5 Fig. 2 shows a diagram of a proposed unified mul- 

tiserver graphics system. 

Fig. 3 shows a diagram of a prior art single server 
graphics and window management system. 

Fig. 4 shows a diagram of a X Window graphics sys- 
70 tern layered over a host graphics system. 

Fig. 5 shows a diagram of the elements of graphics 
system according to a preferred embodiment of the 
present invention. 

Fig. 6 shows a diagram of the window hierarchy ac- 
15 cording to a preferred embodiment of the present inven- 
tion. 

Fig. 7 shows a typical internal window data structure 
according to a preferred embodiment of the present in- 
vention. 

20 Fig. 8 shows on X window tree using instances of 
the window data structure shown in Fig. 7. 

Fig. 9 shows a general control flow diagram for a 
preferred implementation of a window management 
method in accordance with a preferred embodiment of 
25 the present invention. 

Fig. 10 shows a control flow diagram for a Cre- 
ateWindow request. 

Fig. 11 shows some substeps of the control flow out- 
lined in Fig. 9. 

30 Fig. 12 shows a control flow diagram for changes 
to ReparentWindow request processing. 

Fig. 1 3 shows a control flow diagram for a Change- 
BorderWindow routine in a ConfigureWindow request. 
Fig. 14 shows a control flow diagram for changes 
35 tothe routine MoveWindowforthe ConfigureWindow re- 
quest. 

Fig. 15 shows a control flow diagram for a PM 
WM_MOVEWINDOW event. 

Fig. 16 shows a control flow diagram for a PM 
40 WM_MI NM AXFRAME event. 

Fig. 17 shows a control flow diagram for a PM 
WM_SETFOCUS event. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

45 

Reference will now be made in detail to a presently 
preferred embodiment of the invention, an example of 
which is illustrated in the accompanying drawings. 

Fig. 5 shows a preferred embodiment of the data 
50 processing system of this invention. A data processing 
system 500 includes a host server 510, coupled to 
graphics hardware 520 via drivers 515, to provide win- 
dow management services to host clients 522, 525, and 
527. 

55 Display server 530, which is also coupled to host 
server 510, preferably implements the X Window Sys- 
tem protocol. Although display server 530 is configured 
using X Window System protocol, the invention can be 
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practiced with any graphics system having a common 
window manager reconfigurable separate from the serv- 
er. 

The implementation of display server 530 as a client 
of host server 510 is not described in detail because it 
is believed that an acceptable implementation can be 
designed by persons of ordinary skill having knowledge 
of both servers. For example, other X servers that com- 
municate with the display through a host server have 
been designed, including XVision, a Microsoft Win- 
dows-based X server, marketed by Visionware Limited; 
and Mac, an Apple Macintosh-based X server. 

In the preferred embodiment of the present inven- 
tion, the presence and functionality of an X window man- 
ager client (WMCLIENT) 540 is emulated within the X 
display server 530. This emulation is invisible to X cli- 
ents 533 and 538 which cannot detect whether they are 
running in a conventional X Window System or in an X 
Window System according to the preferred embodiment 
of the present invention where the WMCLIENT 540 is 
emulated within the display server 530. The display 
server 530 in this case supplies a virtual window man- 
ager to the operating environment of the X clients. 

In a preferred embodiment, the host server 510 is 
the Microsoft Operating System/2 Presentation Manag- 
er (PM). The host server 510, however, is not restricted 
to the PM, and in fact could be any graphics system hav- 
ing sufficient functionality to support the protocol of the 
system being implemented, which is the X Window Sys- 
tem in the preferred embodiment. 

A. Overview of Server/Window manager Functionality 

X window clients send "requests" to the X window 
server to perform graphics functions. A request is a type 
of message. For example, the CreateWindow request 
designates that a new window be created. 

The X Window server, in turn generates "events" to 
inform clients of the status of a window. For example, 
the CreateNotify event indicates that a certain window 
has been created. When the CreateNotify event is gen- 
erated for a window, it is sent to clients that have des- 
ignated CreateNotify as one of the events they wish to 
receive for that window, by setting an appropriate bit in 
an event mask for that window's parent. 

Fig. 6 includes a diagram 600 of a window hierarchy 
implemented according to the preferred embodiment of 
the present invention. In the X Window System, a win- 
dow is the child of a single parent window. All client-cre- 
ated windows are descendent from a common X root 
window, shown as X_ROOT 601 in Fig. 6. In the pre- 
ferred embodiment the X root window X_ROOT 601 is 
also the host system root window, shown as 
HWS_ROOT 602 in Fig. 6. 

In the X Window System, a window is owned by a 
single client that creates the window by issuing a Cre- 
ateWindow request. 

The functionality of window manager client (WM- 



CLIENT) 540 will now be described with reference to 
Fig. 6, which shows an Xwindowtree after the X window 
server has processed a number of CreateWindow re- 
quests. A Child of the root window that is designated to 
5 be window-managed (by creating the window without an 
override-redirect attribute) may be created by an X cli- 
ent. For example, windows A 61 0, B 620, C 630, D 640 
and E 650 in Fig. 6 were each created as children of the 
root windows. 

70 From a user client point of view, when the client 
makes a request of server 530 to create a window man- 
aged window, for example window A 61 0, the window is 
created as a child of the X root window. After that, WM- 
CLIENT 540 creates a corresponding window, for exam- 
's pie window WM1 605 in Fig. 7 and "reparents" window 
A 610 to be the child of WM1 605. The WMCLIENT 540 
then generates a ReparentNotify event for window A 
605, thereby informing clients of the reparenting of the 
window. 

20 Thereafter, when a client, such as X client 533 in 
Fig. 5, makes a request of display server 530 in Fig. 5 
to map (make visible) a window managed window, for 
example window A 610, the request is redirected to WM- 
CLIENT 540 which then makes a request to map both 

25 window A 610 and WM1 605. UnmapWindow and De- 
stroyWindow requests are also directed to WMCLIENT 
540. 

Similar to the operation of a real window manager, 
such as window manager 330 in Fig. 3, the virtual win- 
so dow manager WMCLIENT 540 of the preferred embod- 
iment does not interfere with the creation, mapping, un- 
mapping, or destroying of a window that a client does 
not wish to be window managed. A client in this case 
creates the window with the override-redirect attribute 
35 in the CreateWindow request. For example, windows F 
660 and Z 680 were created with the override-redirect 
attribute. Regardless of the override-redirect attribute, 
WMCLIENT 540 does not interfere with request 
processing of windows that were not created as the child 
40 of the X root window X_ROOT 601 . Thus, for example 
windows a 611, b 612, d 613, e 614, f 615, g 616, h 617, 
i 618 and y 619 were not created as the child of X root 
window X_ROOT 601 . Therefore they will not be man- 
aged. 

45 

B. Overview of Server/Window Manager Client 
Architecture 

A preferred embodiment for the display server 530 
50 containing WMCLI ENT 540 is a modified version of the 
X Window System sample server Version 11, Release 
4, published by MIT, and the Microsoft Operating Sys- 
tem/2 Presentation Manager (PM) graphics system. 
The modifications to the server are needed to emulate 
55 a window manager. Thus, display server 530 differs 
from the X window sample server in both data structure 
and control flow. For example, the sample server has 
calls to a device dependent layer (DDX). In display serv- 



50 



55 



4 



7 



EP 0 469 709 B1 



8 



er 530, routines of the DDX layer contain calls to PM. 

In the preferred embodiment of the invention shown 
in Fig. 5, the host server 510, has internal window man- 
agement functions. WMCLIENT 540 takes advantage 
of this implementation of window management func- 
tions inside of the host server 51 0 by delegating window 
management functions to host server 510. This delega- 
tion has two principal advantages. First, WMCLIENT 
540 can supply window management functions to X cli- 
ents without implementing those functions within WM- 
CLIENT 540 itself. Second, X client managed windows 
inherit the windowing interface of the PM system so that 
X clients will have a common window interface with host 
clients ("PM clients"). 

With regard to the first advantage, windows WM1 
605, WM2 615, WM3 625, WM4 635, and WM5 645 in 
Fig. 6 are created as "PM frame" windows in server 51 0. 
PM frame windows contain various standard user inter- 
face objects such as buttons and menus, which a user 
can manipulate to perform functions such as moving a 
window. WMCLIENT 540 need not have knowledge of 
or capability to generate these user interface objects, 
and need only he concerned with the results of the us- 
er's manipulation of these objects. As explained below, 
WMCLIENT 540 learns of the results of a user's manip- 
ulation of these objects by receiving PM events. For ex- 
ample, a user may select a button to move a window, 
resulting in WMCLIENT 540 receiving a PM move win- 
dow event, WM_MOVE. 

An additional advantage of delegating window man- 
agement to server 510 is that, if the host system inter- 
face were to change, the X window interface provided 
by WMCLIENT 540 would tend to remain compatible 
with the host system interface without having to be mod- 
ified. 

C. Data Structure Differences 

WMCLIENT 540 must have knowledge of windows 
being created destroyed, mapped, or unmapped. This 
knowledge is necessary because, for example, when a 
window managed X window is unmapped (i.e., removed 
from visibility), the frame window must also be un- 
mapped. 

In order for WMCLIENT 540 to keep track of win- 
dows; certain X system data structures must be modi- 
fied. Fig. 7 shows an X WindowRec window data struc- 
ture 700 modified for use in a preferred embodiment of 
this invention. Portion 71 0 has identifiers from the stand- 
ard part of the X Window System. Identifiers 720 and 
730 are identifiers added to the set of WindowRec iden- 
tifiers to implement the preferred embodiment of the 
present invention. HASBEENMAPPED identifier 720 
controls the suppression of PM 
WM_WI NDOWPOSCH ANG ED and WM_MOVE events 
which host server 510 may generate prematurely. 

hPMWnd identifier 730 is a pointer to a PM window 
structure corresponding to the X window structure. Be- 



cause every X window is implemented as a PM window, 
this pointer allows a translation from X window to corre- 
sponding PM window, which is needed for the process- 
ing of requests. 

5 In addition the PM window data structures (PM- 

REC) must be modified to contain a pointer to the cor- 
responding X WindowRec data structures. This pointer 
allows a translation from PM window to the correspond- 
ing X window, which is needed for the processing of PM 

70 events. Processing PM events by display server 530 
may involve the generation of X events. 

The various X WindowRec data structures are 
linked together to form an X window tree which allows 
display server 530 to find related windows. Fig. 8 shows 

15 a diagram mapping X windows represented by X Win- 
dowRec data structures 801, 803, 805 into the corre- 
sponding PM windows represented by PMREC struc- 
tures 802, 804, 806. The hPMWnd identifiers in struc- 
tures 801, 803 and 805 point to corresponding PMRECs 

20 802, 804 and 806, respectively which also point back to 
the corresponding X WindowRec . 

In the preferred embodiment, the correspondence 
allows X display server 530 to receive a request for an 
X window and then issue a PM request for the corre- 

25 sponding PM window. 

D. Control Flow Differences 

Although the virtual window manager WMCLIENT 

30 540 (Fig. 5) appears to be a separate process from dis- 
play server 530 when viewed outside of display server 
530, in the preferred embodiment, display server 530 
and WMCLIENT 540 share a common address space 
within a common process. 

35 Further, to achieve certain efficiencies, the code im- 
plementing WMCLIENT 540 is intertwined with the code 
implementing the other portions of display server 530. 
In other words, WMCLIENT 540 is a procedure com- 
posed of a first set of interrelated computer instructions, 

40 and the part of display server 530 responsible for exe- 
cuting the graphics operation request directly is a sec- 
ond procedure composed of a second set of interrelated 
computer instructions interspersed with the computer 
instructions of WMCLIENT 540. Because the two sets 

45 of computer instructions are interspersed, execution of 
the two procedures is interleaved. 

As described previously, the invention includes the 
steps of receiving a graphics request from a client, such 
as X client 533, and submitting the request to an emu- 

50 lated management client, such as WMCLIENT 540. In 
the preferred embodiment, of the emulated manage- 
ment client, WMCLIENT 540, is implemented with con- 
ditional statements dispersed throughout the X window 
sample server. For example, if the request being proc- 

55 essed requires redirection, supplemental calls to re- 
quest dispatch routines are performed inline. This has 
the effect of simulating the requests that a window man- 
ager would submit in response to receiving a redirected 
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request. 

Code to be added to an X window sample server in 
order to implement WMCLIENT 540 will be discussed. 
Unless otherwise specified, routine names used in the 
discussion that follows refer to routines in the X window 
sample server version 1 1 , Release 4, published by MIT. 
All OS/2 PM routine names are identified by "PM." 

1 . Initialization 

All PM clients require that the entry point be named 
MAIN. Therefore, one modification to the X window 
sample server is to rename the entry point named MAIN 
to be XMAIN, and modify it. Anew routine, MAIN, is writ- 
ten to initialize the PM environment, and then MAIN calls 
XMAIN. This initialization includes a call to PM WinReg- 
isterClass to register a PM window class. This PM call 
causes extra storage in the PM window data structure 
(PMREC) to be allocated for the pointerto a correspond- 
ing X WindowRec data structure. Because XMAIN may 
return when server 530 closes down ; MAIN closes down 
the PM environment after the call to XMAIN. 

From the viewpoint of clients, the virtual window 
manager client WMCLIENT 540 must appear to be just 
another client connected to the server and possessing 
resources such as windows. To achieve this end, the 
status of WMCLIENT 540 is represented in display serv- 
er 530 with many of the same data structures that would 
be used to represent other X clients. This representation 
is implemented with steps performed in the initialization 
section of the sample server where display server 530 
allocates data for WMCLIENT 540. The data initializa- 
tion for WMCLIENT 540 is performed after the "server 
client ; " which owns certain resources including the root 
window, is created and initialized. 

The data initialization for WMCLIENT 540 includes 
allocating a data structure (not shown) for the client and 
placing the data structure at a predefined position in dis- 
play server 530's client array. InitClientResources is 
called for WMCLIENT so that space is allocated in the 
client resources table for resources such as windows, 
fonts, pixmaps, and graphics contexts. A client counter 
(not shown) in Display server 530 is increased by 1 to 
signify the existence of WMCLIENT 540. 

In the routine CreateRootWindow, PM WinCre- 
ateWindow is called to create a PM object window, 
shown as X_ROOT 601 in Fig. 6, which is equivalent to 
HWS_ROOT 602. (The PM object window is a special 
PM window, having no parent, that will own the PM 
frame windows) The display server 530 owned X root 
window is associated with the PM root window by setting 
the X WindowRec structure to point to the PM root win- 
dow: pWin^hPMWnd = HWND_DESKTOP. WMCLI- 
ENT 540 makes itself eligible to receive certain events 
in which a window manager would be interested, by set- 
ting an event mask for the X root window: pWin^event- 
Mask = ResizeRedirectMaskl SubstructureRedirect- 
Mask. Because only one client can set the ResizeRedi- 



rectMask and SubstructureRedirectMask fields in an 
event mask for a certain window, WMCLIENT 540's set- 
ting these fields in a root window event mask prevents 
another window manager from providing common man- 
5 agement functions for all clients. 

2. Request Processing 

Fig. 9 shows a general flow diagram 900 for request 

70 processing in the preferred embodiment. First, a request 
for graphics operation is received by display server 530 
from an X client (step 910). Next, display server 530 de- 
termines whether the request requires performance of 
window management functions (step 920). This deter- 

15 mination, discussed in greater detail below, generally in- 
volves a test of the status of the window to which the 
request relates. If the request does not require window 
management functions, then it is executed as dictated 
by the request (step 930). If the request does require 

20 window management functions, the request is submit- 
ted to the emulated manager WMCLIENT 540 (step 
940). In the preferred embodiment, the step of submit- 
ting (step 940) is implemented by following WMCLI ENT 
540 execution path, which exists in the same address 

25 space as the execution path of the executing step (step 
930). 

For certain requests, the invention allows for the 
step of submitting (step 940) to include the substep of 
executing the request directly, as dictated by the re- 
30 quest, before submitting the request to the emulated 
manager. 

Steps 920, 930 and 940 will now be described in 
greater detail in the discussion of the implementation of 
specific requests. 

35 Fig. 10 shows a flow chart 1000 for handling the 
CreateWindow request. First a new WindowRec struc- 
ture is allocated for the window to be created (step 
1010). If the new window is the root window (step 1 01 5) 
normal processing is avoided because the X root win- 

40 dow has been created and is owned by the server client. 
Next a determination is made to see whether man- 
agement functions are required (step 1017). This is es- 
sentially the determination made in step 920 of Fig. 9. 
In order to determine whether the request requires win- 

45 dow management, a check is performed to see whether 
the window is to be created as child of root window and 
without the override-redirect attribute. If both conditions 
are true, the CreateWindow request is for a window to 
be managed. If either condition is false, the request is 

50 treated as if it were for a nonmanaged window, as in 
step 930 in Fig. 9. 

The first step in responding to a request from a non- 
managed window involves translating the coordinates 
of the window to be created from X coordinates to PM 

55 coordinates (step 1020). This translation is necessary 
because in the X Window System the origin of a window 
is the upper lefthand corner, while in the PM window sys- 
tem the origin of a window is the lower lefthand corner. 
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Next, a PM window without user interface objects (PM- 
REC) is created (step 1025). A pointer to an X Window- 
Rec is then saved in the PMREC just created (step 
1030), and a pointer to the PMREC is saved in the X 
WindowRec (step 1 035) ; thus creating an addition to an 
X window tree, such as the one shown in Fig. 8. Finally, 
a CreateNotify event is generated to inform clients of the 
creation of a new window (step 1040). 

If the CreateWindow request does require window 
management function (step 1017), the rightmost branch 
of the flowchart 1000 beginning with step 1050 is fol- 
lowed. Steps 1050-1095 correspond to the emulation of 
a window manager inside of the display server and re- 
ceiving windowing requests from the emulated manager 
as in step 940 of Fig. 9. 

The emulation begins with the calculation of an X 
window origin to the WMCLIENT 540 parent of the re- 
quested window to be created. This calculation is based 
on the requested window's width, height, and border 
size (step 1050). It also involves translation of X coor- 
dinates to PM coordinates. Next, the origin of the PM 
frame window relative to the PM root window is calcu- 
lated such that all, or as much as possible, of the PM 
frame window is visible on the screen (step 1 055). Next, 
both the requested and the PM frame windows are cre- 
ated (step 1060). Preferably this window creation uses 
a call to PM WinCreateStdWindow to create a frame 
window using a style that includes a title bar, system 
menu, size border, and the minimum and maximum con- 
trol features. 

After the call to WinCreateStdWindow, the status of 
the newly created requested and frame windows is up- 
dated (step 1070). This preferably involves four calls to 
PM routines. The first is a call to PM WinSetWindowU- 
Long to save a pointer to the newly allocated Window- 
Rec structure of the requested window in PM window 
structure. Next a call to WinSetWindowPos is made to 
set the position and size of the frame window. Then a 
call is made to PM WinSetOwner to set the owner of the 
frame window to be the PM object window X_ROOT 
601 , described earlier. Finally, a call is made to PM Win- 
SetOwner to set owner of the requested window newly 
created to be the frame window newly created. 

After updating the window status, the hPMWnd field 
of the WindowRec data structure of the requested win- 
dow is set to point to the new PMREC (step 1 080). This 
is done so that X display server 530 and WMCLIENT 
540 can process subsequent requests for the new X 
window by processing the corresponding PM window. 

Next, a CreateNotify event is generated (step 
1090), as required by the X protocol. Finally, an X win- 
dow corresponding to the newly-created PM frame win- 
dow is created as a parent of the newly created X win- 
dow (step 1095). This completes the management of the 
CreateWindow request performed by WMCLIENT 540. 

Fig. 11 shows a flow diagram 1100 to explain a pre- 
ferred method for creating the X window as a parent 
(step 1095). To create an X window as parent, first a 



new X WindowRec data structure is allocated for the PM 
frame window just created (step 1110). 

The X WindowRec structure is then initialized (step 
1120). This is preferably accomplished in two steps. 

5 First, a client part of the ID field of the DrawableRec 
structure, shown in portion 710 (Fig. 7), is set to "1" to 
indicate that WMCLIENT 540 is the owner of the win- 
dow. Then the X WindowRec parent field is set to indi- 
cate that the root window is the parent. 

70 The requested window is then removed from its sib- 
ling chain (step 1130) because the requested window 
will no longer be a sibling to the child of root windows 
after the reparenting. 

Next ; the X window just created, owned by WMCLI- 

15 ENT 540 and corresponding to the new PM frame win- 
dow, is inserted as a child of the X root window. This 
new X window is placed at the top of the stacking order 
of the children of the root window, and the requested 
window is inserted as child of the WMCLIENT 540 

20 owned X window (step 1 1 40). 

The PM window status is then updated (step 1 1 50). 
This is preferably accomplished by calling PM Win- 
SetWindowU Long to save the pointer to the WMCLIENT 
X WindowRec structure in a PMREC. 

25 Following the PM window adjustment, the X Win- 
dowRec structure is updated (step 1160). In the pre- 
ferred embodiment, this is done by setting the hPMWnd 
field of the X WindowRec structure with the pointer to 
the PMREC for the frame window. 

30 Next, a routine AddResource is invoked for the new- 
ly-created window, so that the window will be recorded 
as a system resource (step 1170). Finally, a Reparent- 
Notify event is generated for the window as required by 
the X protocol (step 1180). 

35 A ReparentNotify event is also generated by the 
ReparentWindow request. A ReparentWindow request 
may involve a change in the window management sta- 
tus of the requested window, causing an unmanaged 
window to become managed or a managed window to 

40 become unmanaged. Fig. 12 includes a flow diagram 
1200 of a procedure to make additions needed to the 
routine ReparentWindow. The standard sample server 
code that makes the requested window a child of the 
parent specified in the ReparentWindow request is not 

45 shown. 

For purposes of ReparentWindow request process- 
ing, a window is one of three types: 1 ) POPUP, meaning 
that the window has the override-redirect attribute and 
is child of the root; 2) WINDOWMANAGED, meaning 

50 that the requested window presently has a WMCLIENT 
owned frame window as its parent; and 3) LOWER, 
meaning the requested window is neither the child of the 
root window nor a child of a WMCLIENT window. 

First, the current type of the requested window is 

55 determined, as is the future type of the window after 
reparenting (1201 ). The results of these determinations 
can be classified into one of three cases. Case 1 shown 
in Fig. 12 occurs when a LOWER is reparented to be a 
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POPUP, a LOWER is reparented to stay a LOWER or a 
POPUP is reparented to become a LOWER. Each of 
these indicates that there is no change in window man- 
agement status. The new PM parent is set by calling PM 
WinSetParent (step 1203). Finally, the newly reparented 
window is moved to the position, relative to the parent 
origin, specified in the ReparentWindow request (step 
1204). 

Case 2 shown in Fig. 12 occurs when a LOWER or 
POPUP is reparented to be WINDOWMANAGED, and 
indicates a change to the window management status 
of the requested window, as the requested window is 
changed from being a nonmanaged (LOWER or POP- 
UP) window to a managed (WINDOWMANAGED) win- 
dow. Thus steps 1 206-1 208 in Fig. 1 2 involve converting 
a PM nonmanaged window to a PM managed window 
having a PM frame window. 

First, a pair of PM windows corresponding to the 
requested window and a frame window is created (step 

1206) with processing similarto PM CREATE WINDOW, 
whose control flow was outlined in Fig. 10. WMCLIENT 
540 will own the newly-created PM frame window, and 
the newly-created PM window of the requested window 
will replace the old PM window of the requested window 
specified in the reparent window request. 

Children of the old requested PM window are then 
reparented to the newly-created PM window (step 

1207) , and the old requested PM window is then de- 
stroyed (step 1208). PM data for the old requested win- 
dow need not be transferred to the newly-created re- 
quested window, since in the preferred embodiment, 
display server 530 does not store window pixel data in 
a backing store. 

The conditions for case 3 shown in Fig. 12 are the 
inverse of case 2. Case 3 also indicates a change in 
window management status but occurs when a WIN- 
DOWMANAGED window is being reparented to be a 
LOWER or POPUP. The status of the requested window 
is being changed from window managed (WINDOW- 
MANAGED) to nonwindow managed (LOWER or POP- 
UP). The processing is similar to case 2. 

First, a single PM window is created with processing 
similar to PM CRE ATEWINDOW shown in Fig. 1 0 (step 

1209) . Children of the old requested PM windows are 
then reparented to the new requested window (step 

121 0) . The old PM frame window and old requested PM 
window are destroyed by a call to PM Wi nD est roy Win- 
dow (step 1211). Finally the old X frame window is re- 
moved from the resource list with a call to FreeResource 
(step 1212). 

Fig. 1 3 and 1 4 shows additions needed to two rou- 
tines for WMCLIENT 540 in the ConfigureWindow re- 
quest code. 

In one routine, ChangeBorderWidth, processing 
must be performed to account for the fact that, in the X 
Window System, a window has two origins. The first or- 
igin is used to measure a window position relative to its 
parent and is located on the outside upper left hand cor- 



ner of the window border. The second origin is for draw- 
ing and it is located on the inside upper left hand corner 
of the window border. In PM coordinates, the width and 
height of a window grow by twice the change in border 
5 width. 

Flow diagram 1300 in Fig. 13 explains the change 
required. First it must be determined whether the re- 
quested window requires window management func- 
tions (step 1301). This is preferably done by testing 

70 whether the parent is owned by WMCLI ENT 

If the request does not require management, PM 
WinQueryWindowPos is called to get the current win- 
dow width and height (step 1 302). A new window width 
and height are calculated based on the current request- 
's ed border widths (step 1 303), and a new window origin 
is calculated (step 1304). The calculation of a new PM 
origin is required, even though the X window origin did 
not change, because of the upper lefthand corner loca- 
tion of an X window origin being different than the lower 

20 lefthand corner location of a PM window origin, as ex- 
plained earlier. Finally, the new window height, width, 
and origin are set with a call to PM WinSetWindowPos 
(step 1305). This call to PM WinSetWindowPos per- 
formed for step 1305 will generate a PM WM_MOVE 

25 event, as well as a PM WM_WINDOWPOSCHANGED 
event, because in step 1 305 the window moves relative 
to the parent and changes size. 

If the request does require window management 
functions (step 1301) PM WinQueryWindowPos is 

30 called to get the current width and height (step 1 306). A 
new width and height are calculated (step 1307), but a 
new origin is not calculated. A new origin is not calcu- 
lated because the requested window will not move rel- 
ative to the parent, which is the frame window. Finally, 

35 a new width and height are set with a call to PM Win- 
SetWindowPos, which will generate the PM 
WM_WINDOWPOSCHANGED event (step 1308). 

Fig. 1 4 contains flow diagram 1 400 to illustrate the 
change to the routine MoveWindow, which will be called 

40 if the ConfigureWindow request is moving a window rel- 
ative to its parent. The added steps are performed to 
prevent clients from moving a frame window owned by 
WMCLIENT 540. Thus, in the preferred embodiment, 
managed windows can only be moved from the PM side 

45 via the PM user interface objects. 

In flow diagram 1400 first it is determined whether 
the requested window requires window management 
functions by testing whetherthe parent window is a WM- 
CLI ENT owned frame window (step 1410). 

50 The new PM window position is then calculated 
(step 1430). Finally, PM WinSetWindowPos is called to 
set the new PM position (step 1440). 

MapWindow request processing has code in the 
routine MAPWINDOW to set the HASBEENMAPPED 

55 field of the X WindowRec structure, shown as 720 in Fig. 
7, to true. This is done so that PM WM_MOVE and 
WM_WINDOWPOSCHANGE events can be discarded 
until the window has been mapped at least once. 
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MapWindow request processing has code to handle 
the case where a ChangeWindowAttributes request has 
changed the window management status of the request- 
ed window by adding or deleting the override-redirect 
attribute on the window. There will be a change in win- 
dow management status if a child of a WMC LIE NT- 
owned window has the override-redirect attribute, in 
which case the window should go from a managed state 
to a non managed state; or if a child of the root window 
does not have the override-redirect attribute, in which 
case the window should go from a nonmanaged state 
to a managed state. If either of these two cases occur, 
a routine similar to ReparentWindow is called with pa- 
rameters to indicate that the root window is the new par- 
ent. 

The MapWindow request has code in the routine 
pm MapWindow to map the PM frame window, if the win- 
dow being mapped is window managed, rather than the 
PM window corresponding to the requested window. 
Mapping the PM frame window will map both the WM- 
CLIENT 540-owned frame and the requested window, 
and will generate a MapNotify event for each of the WM- 
CLIENT 540-owned frame and the requested window. 

The UnmapWindow request has code in the routine 
pmUnmapWindow to unmap the PM frame window, if 
the window being unmapped is window managed, rath- 
er than the PM window corresponding to the requested 
window. Code additions for window unmap processing 
does not include setting the HASBEENMAPPED field to 
false, as that field indicates whether the window has 
been mapped at least once. Unmapping the PM frame 
window will unmap both the WMCLIENT 540-owned 
frame and the requested window, and will generate an 
UnmapNotify event for each of the WMCLIENT 
540-owned frame and the requested window. 

In processing the DestroyWindow request, a check 
is performed to determine if the window being destroyed 
has a WMCLIE NT-owned window as parent. If so, a call 
to FreeResource is performed for the WMCLIE NT- 
owned X window. Further, if a window-managed window 
is being destroyed, then a call to the PM routine WinD- 
estroyWindow is performed for the PM frame window 
instead of the requested window. The call to PM DE- 
STROYWINDOW in this case will destroy both the 
frame window and the requested window. If the window 
being destroyed does not have a WMCLIENT-owned 
window as parent, the requested window is destroyed. 

In the X Window System, each window may have a 
number of named "properties," which are collections of da- 
ta. A suggested feature, though not completely implement- 
ed in the preferred embodiment, involves the processing 
of properties in the routines ProcChange Property and Pro- 
cRotateProperties. If certain properties (such as 
WM_NAME, WM_ICON_NAME, WM_NORMALHINTS, 
WMJHINTS and WM_TRANSIENT_FOR) change be- 
cause of a request, certain PM routines would be called as 
a result. For example, if the WM_NAME property were to 
change and the requested window were being displayed, 



PM WinSetWindowText would be called to change the 
name in the requested window's title bar. Another example 
would be when the icon_pixmap (a PIXMAP for a compact 
representation of a window, called an "icon"), which is a 
5 subcomponent of the WMJHINTS property, were to 
change and the requested window were to be in an iconic 
state, PM routines would be called to draw the new PIX- 
MAP into the iconified window. 

70 3. Processing Outgoing X Events 

In the X Window System, the X display server in- 
forms clients of the status of a window by sending X 
events. Normally, a window manager would be eligible 

75 to receive X events, as a window manager is just anoth- 
er client. In the preferred embodiment, however, X 
events that would normally be sent, to a window man- 
ager/client are not sent to the window manager client 
WMCLIENT 540 because WMCLIENT 540 does not set 

20 any event masks. Instead, display server 530 contains 
WMCLIENT 540 X event processing code at places 
where the events are generated in display server 530. 

4. Processing Incoming PM Events 

25 

In the PM system, the PM server informs PM clients 
of the status of a window by sending PM events. In the 
preferred embodiment, X display server 530, being a 
PM client, receives PM events from host server 510. Fig. 
30 15 shows a control flow diagram 1500 for processing 
the PM WM_MOVE event received from host server 
510. 

There are at least two ways to receive the PM 
WM_MOVE event. The first way is that the user moves 

35 the window using one of the PM user interface objects. 
The second way is for a client, such as X client 533 con- 
nected to display server 530, to move, resize, or change 
the border width on the window with a ConfigureWindow 
request, which causes display server 530 to send a PM 

40 request to host server 510. This will in turn cause the 
host server 510 to issue a PM WM_MOVE event. 

Fig. 15 shows a control flow diagram 1500 for the 
routine HandlePMMoveMessage. PM WinQueryWin- 
dowULong first is called to get a pointer to the X Win- 

45 dowRec structure of the moved window (step 1501). 
Second, it is determined whetherthe moved window has 
been mapped by testing the HASBEENMAPPED field, 
shown at 720 in Fig. 7 (step 1502). 

If the window has never been mapped, normal 

so processing is bypassed, as the PM WM_MOVE event 
will contain meaningless data. If the window has been 
mapped, it is determined whether the moved window re- 
quires window management functions (step 1503). This 
is done by determining whether the window has a WM- 

55 CLIENT 540 owned window as its parent. 

If the window is being managed, WinQueryWindow- 
Pos is called to get the frame window's size and position 
(step 1504), and new X window coordinates are calcu- 
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lated and set in the frame window's X WindowRec (step 
1505). The coordinates, called drawable. x, drawable. y, 
origin. x, origin.y, are set in portion 71 0 of the X Window- 
Rec structure 700 (Fig. 7) of the parent window. 

The remaining processing is performed regardless 
of whether the moved window requires management. 
This processing includes calling PM WinQueryWindow- 
Pos to get the PM coordinates for the moved window 
(step 1 506). New coordinates for the X window are cal- 
culated (step 1 507), and the new coordinates are set in 
the X WindowRec structure 700 (step 1508). 

Next, it is again determined whether the window re- 
quires window management functions by checking 
whether the window has a WMC LIE NT-owned window 
as parent (step 1 509). If the window is not window-man- 
aged, a ConfigureNotify X event is generated for the 
window (step 151 0). The ConfigureNotify X event is sup- 
pressed if the window has a WMCLIENT 540-owned 
window as parent because the processing of steps 1 504 
and 1 505 ensures that the moved window will not move 
relative to its parent (the WMCLIENT frame window). 

Finally ResizeChildrenWinSize is called with the 
change in the coordinates origin. x and origin.y for the 
window so the relative drawable positions of the win- 
dow's children can be updated (step 1511). 

Processing for the PM WM_WINDOWPOSCHAN- 
GE event is similar to processing for the PM WM_MOVE 
event outlined in Fig. 1 5. One difference is that the steps 
of setting new coordinates (steps 1505 and 1508) also 
includes the steps of setting the width and height pa- 
rameters for the window called drawable. width and 
drawable. height in portion 710 portion of the X Window- 
Rec structure 700 (Fig. 7). Another difference is that the 
ConfigureNotify event (step 1510) is generated regard- 
less of whether the moved window is managed, be- 
cause the WM_WINDOWPOSCHANGE message may 
change the size of the window regardless of whether the 
window is window managed. 

The PM user interface objects allow the user to 
"minimize" a window, causing the window to be dis- 
played in a compact form called an "icon", or "restore" 
a window, causing the windowto be displayed in the nor- 
mal manner. Fig. 16 outlines processing for the PM 
WM_MINMAXFRAME event, which is generated when 
the user minimizes or restores a window. First PM Win- 
Query WindowU Long is called to get a pointer to the X 
WindowRec structure of the affected window (step 
1605). It is determined whether the user has minimized 
or restored the window (step 1610). Processing of the 
PM WM_MINMAXFRAME event involves calling PM 
WinSetWindowText using conventional X properties. 
Thus, if the user has minimized the window, the 
WM_ICON_NAME property, if defined, is used to call 
WinSetwindowText to set the window icon name field 
(step 1615). (A suggested feature, though not imple- 
mented in the preferred embodiment, is to read the 
WM_HINTS property and to draw the icon pixmap into 
the minimized window, provided the property 



icon_pixmap in WM_HINTS is defined.) The X Window- 
Rec structure is checked to determine whether WMCLI- 
ENT 540 is the owner of the indicated window, meaning 
that management is required (step 1620). If manage- 
5 ment is required, WMCLIENT 540 sends an UnmapWin- 
dow request for the managed window and the frame 
window to display server 530, thereby causing display 
server 530 to generate an UnmapNotify event for each 
window. 

70 |f the user has restored the window, the WM_N AME 
property, if defined, is used to call WinSetWindowText 
to set the name in the window's title bar (step 1 630). The 
X WindowRec structure is checked to determine wheth- 
er WMCLIENT 540 is the owner of the indicated window, 

15 meaning that management is required (step 1635). If 
management is required, WMCLIENT 540 sends an 
MapWindow request for the managed window and the 
frame window to display server 530, thereby causing 
display server 530 to generate an MapNotify event for 

20 the window (step 1 640). 

The PM WM_SETFOCUS signifies a change in "in- 
put focus, " meaning that a window is either acquiring or 
losing eligibility to receive keyboard input. The PM 
WM_SETFOCUS event can originate either from PM, 

25 after the user changes the input focus with one of the 
user interface objects, or from an X client after an X cli- 
ent generates a SetlnputFocus request. 

Fig. 1 7 contains a control flow diagram 1 700 setting 
forth processing added to the routine DoFocusChange. 

30 First, a pointer to the X WINDOWREC for the X window 
corresponding to the PM window designated in the PM 
WM_SETFOCUS event is obtained by calling PM Win- 
QueryWindowULong (step 1701). 

Next, data bases are updated to reflect the change 

35 in input focus by calling DoFocusEvents to designate 
that the X window is gaining keyboard input focus and 
that no window is losing keyboard input focus, or that 
the X window is losing keyboard input focus and that no 
window is gaining keyboard input focus, depending on 

40 whether the WM_SETFOCUS event designates that the 
X window is gaining focus (step 1702). 

It is then determined whether management func- 
tions are required by checking whether the X window 
has a WMCLIENT-owned window as parent (step 

45 1703). If management functions are not required, the 
root window X_ROOT 601 (Fig. 6) is designated as the 
window for which input events are generated if no client 
solicits input events for the X window (step 1704). This 
designation is effected by setting the FocusClassRec 

50 data structure: focus^revert=RevertToPointerRoot. 

If the window does require window management 
functions, then the WMCLIENT 540-owned window par- 
ent is designated as the window for which input events 
are generated if no client solicits input events for the X 

55 window (step 1705). This designation is effected by set- 
ting the FocusClassRec data structure: focus^re- 
vert=RevertToParent. The WMCLIENT 540-owned win- 
dow is moved to the top of the stacking order by calling 
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the sample server routines MoveWindowIn Stack and 
WindowsRestructured (step 1706). 

D. CONCLUSION 

With the X display server window manager client 
according to the preferred embodiment, a server is pro- 
vided which can be implemented using the support tech- 
nology of an existing server. Clients of the two servers 
can access the same graphics hardware while present- 
ing a uniform user interface. Remote X Window Sys- 
tems need not have knowledge of the type of host sys- 
tem in order to start a compatible manager. 

Additional advantages and modifications will readily 
occur to those skilled in the art. The invention in its 
broader aspects is therefore not limited to the specific 
details, representative apparatus, and illustrative exam- 
ples shown and described. Accordingly, departures may 
be made from such details without departing from the 
scope of the invention as defined in the accompanying 
claims. 

For example, there are alternative ways to imple- 
ment the submitting step and the emulating step. One 
way would be to take advantage of the fact that the sam- 
ple server executes one request at a time, and uses 
events to redirect requests to a window manager client. 
Instead of dispersing WMCLIENT 540 throughout the 
server WMCLIENT 540 could be made more modular. 
After a display server 530 receives a request from a user 
client, if the request is to be redirected to the window 
manager then display server 530 generates an appro- 
priate event, thereby informing WMCLIENT 540 of the 
request. 

The WMCLIENT 540 event handling procedure, in 
emulating a window manager's handling of an event, 
may submit its own requests to display server 530 by 
calling the appropriate display server 530 request 
processing routine directly. However, some conditional 
statements that change the execution flow when the cur- 
rent request is from WMCLIENT 540 could be dispersed 
throughout the server. This would be needed because 
there are various places in the server where responding 
to a request as if it had come from a normal client would 
be inappropriate. 

Thus, WMCLIENT 540 could be a procedure com- 
posed of a set of interrelated computer instructions or- 
ganized as a callable module, and the part of display 
server 530 responsible for executing requests directly 
could be a different procedure. In such a design, it fol- 
lows that the emulation of the management client by 
WMCLIENT 540 is performed at a different time than 
the execution of the functions in the graphics operation 
request directly. 

Further, the window manager need not reside in the 
same address space as the server and may instead be 
a separate process. Another possibility is that the win- 
dow manager could be some arbitrary structure, not 
necessarily code. Instead, management functions could 



be performed by a data base or lookup table. 

In addition, although in the preferred embodiment 
the display server sends requests to the host server to 
communicate with the display, in an alternative imple- 

5 mentation the display server could communicate with 
the hardware more directly and the host server could 
communicate with the hardware by sending requests to 
the display server. Another possibility is that the display 
server could have a common interface to the hardware 

70 along with the host server. 

Claims 

15 1. A method for providing a uniform windowing inter- 
face comprising the steps, performed by a display 
server (530), of : 

emulating in the display server a management 

20 client (540) that provides graphics manage- 

ment functions for a plurality of clients 
(533,538), the management client emulating 
step including the substep of : 

recording, in a data structure of said dis- 

25 play server, information identified that the man- 

agement client is in existence; 
determining (920) whether the graphics opera- 
tion request requires performance of window 
management functions; 

30 submitting (940) the graphics operation request 

to the management client (540) if the graphics 
operation request requires performance of win- 
dow management functions; 
translating (1050-1095) by said management 

35 client (540), the graphics operation request re- 

quiring performance of window management 
functions into a set of graphics operation re- 
quests having a second format suitable for use 
by a second ; different display server (51 0); and 

40 executing (930) functions in the graphics oper- 

ation request directly that do not require win- 
dow management functions. 

2. A method according to claim 1 , wherein the step of 
45 emulating the management client (540) includes 

the substep of : 

generating a user interface for a display, said 
user interface providing an appearance and control 
functions for each of the clients. 

50 

3. A method according to claim 2, wherein the method 
further includes the step of : 

sending messages from the display server 
(530) to the second server (510) to communicate 
55 with the display (520). 

4. A method according to claim 3, wherein the second 
server (51 0) sends messages to the display server 
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(530), and the second server includes an interface 
having user interface objects, wherein the substep 
of generating the user interface includes the sub- 
step of : 

receiving a message from the second server s 
when a user selects one of the user interface ob- 
jects. 

5. A method according to claim 2, wherein the method 
further includes the step of : 10 

sending messages from the display server to 
an interface to the display. 

6. A method according to claim 1 , wherein the graph- 
ics operation requests include requests (1000) to is 
create a window, wherein the step of executing in- 
cludes the substep of : 

processing a request to create window by 
sending a message to the second server (510) to 
create (1060) at least one window. 20 

7. A method according to claim 1 , wherein the method 
further includes the steps of : 

receiving a message from the second server 25 
(510); 

translating (1500) the received message into a 
set of display server messages; 
determining a corresponding set of clients 
(533,538) to receive the set of display server 30 
messages; and 

submitting the set of display server messages 
to the corresponding set of clients. 

8. A method according to claim 7, wherein the step of 35 
submitting the graphics operation request to the 
management client (540) includes the substeps of : 

translating a selected one of the display server 
messages in the set of display server messag- 40 
es received from the display server into a set 
of messages; 

determining a corresponding set of clients 
(533,538) to receive the set of messages; and 
submitting the set of messages to the corre- 45 
sponding set of clients. 

9. A method according to claim 7, wherein the substep 
of submitting the set of display server messages to 

the corresponding set of clients (533,538) includes so 
the substep of : 

determining whether one of the clients in the 
set of clients is the emulated management cli- 
ent; and 55 
executing a set of computer instructions to em- 
ulate the management client if one of the clients 
in the set of clients is the emulated manage- 



ment client. 

10. A computer system comprising : 

a display (520); 

client processor means (533,538) for executing 
clients; and 

server processor means (530), coupled to the 
display and to the client processor means, for 
responding to graphics operation requests gen- 
erated by said clients, said graphics operation 
requests having a format suitable for use by 
said server processor means (530), the server 
processor means including : 

means (540) for emulating a management 
client (510) that provides graphic manage- 
ment functions for the clients; 
a data structure for recording information 
identifying that a plurality of clients includ- 
ing the management client are in exist- 
ence; 

means (530) for receiving the graphics op- 
eration request from the clients (533,538); 
means, coupled to the receiving means, for 
determining whether the graphics opera- 
tion requests require windows manage- 
ment; 

means, coupled to the receiving means 
and to the determining means, for directly 
executing the graphics operation requests 
which do not require window management; 
means, coupled to the receiving means 
and to the determining means, for submit- 
tingtothe emulated management client the 
graphics operation requests that do require 
window management; and 
means, coupled to said emulated manage- 
ment client, for translating said graphics 
operations requests that do require win- 
dow management into corresponding sets 
of graphics requests having a second for- 
mat suitable for use with a second, different 
server processor means. 

11. A system according to claim 1 0, wherein the emu- 
lated management client (510) includes : 

means for submitting the corresponding sets 
of graphics requests to the server processor means 
(530). 

12. A system according to claim 1 1 , wherein the means 
(540) for emulating the management client 
includes : 

means for generating a user interface on the 
display, said user interface providing a uniform ap- 
pearance and control functions for each of the cli- 
ents. 
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13. A system according to claim 12, further comprising 
another server (51 0), coupled to the server proces- 
sor means (530) and the display (520), wherein said 
other server includes : 

means for processing said graphic operation 
requests having said second format; and 
wherein the server processor means (530) 
includes : 

means for sending messages to the other 
server to communicate with the display. 

14. A system according to claim 13, wherein the other 
server (510) includes means for providing window 
management functions. 

15. A system according to claim 14, wherein the other 
server (510) includes : 

means for sending messages to the display 
server (530); and 

means for generating user interface objects for 
manipulating window status, wherein the 
means for generating the user interface 
includes : 

means for receiving a message from the 
other server when a user manipulates one of 
the user interface objects. 

16. A system according to claim 13, wherein requests 
for graphic operations generated by clients include 
requests to create a window, and the other server 
includes means for creating windows that may ap- 
pear on the display, wherein the means for gener- 
ating the user interface includes: 

means for responding to a request to create 
a window by sending a message to the other server 
to create a window. 

17. A system according to claim 12, further comprising 
another server for generating a user interface, the 
other server including : 

means for sending requests to the server 
processor means to communicate with the display. 

18. A system according to claim 12, further comprising : 

an interface to the display; and 
another server including : 

means for sending messages to the inter- 
face to the display; and 
wherein the server processor means 
includes : 

means for sending messages to the 
interface to the display. 



19. A system according to claim 10, wherein the means 
(540) for emulating includes : 

a first set of computer instructions in a first ad- 
5 dress space; and 

wherein the means for executing the graphics 
operation request directly includes : 

a second set of computer instructions in 
the first address space. 

w 

20. A system according to claim 1 0, wherein the means 
(540) for emulating the management client 
includes : 

15 a first set of computer instructions in a first ad- 

dress space; 

wherein the means for executing the graphics 
operation request directly includes : 

a second set of computer instructions in 
20 an address space different from the first ad- 

dress space. 

21 . A system according to claim 1 0, further comprising : 

25 another server, the other server including : 

means for generating messages; 
wherein the server processor means includes : 

means for receiving messages from the 
30 other server: and 

means for translating a received message 
into a corresponding set of display server 
messages; 

means for determining a set of clients to re- 
35 ceive the set of display server messages; 

and 

means for submitting the set of display 
server messages to the set of clients. 

40 22. A system according to claim 21, wherein the emu- 
lating means includes : 

means for receiving a display server message 
from the means for submitting the set of display 
45 server messages: 

means, coupled to the receiving means, for 
translating the received display server mes- 
sage into a set of messages; and 
means, coupled to the translating means, for 
50 determining a set of the clients to receive the 

set of messages produced by the translating 
means. 

23. A system according to claim 21 , wherein means for 
55 submitting the set of messages to the set of clients 
includes : 

means for determining whether one of the cli- 
ents in the set of its clients is the management cli- 
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ent. 



Patentanspriiche 

5 

1 . Verfahren zum Erzeugen einer Schnittstelle fur ein- 
heitliche Fenster, das die folgenden von einem An- 
zeigeserver (530) ausgefuhrten Schritte enthalt: 

Emulieren eines Management-Clients (540) im 10 
Anzeigeserver, wobei der Management-Client 
Graphikmanagementfunktionen fur mehrere 
Clients (533, 538) schafft, wobei der Manage- 
ment-Client-Emulationsschritt den folgenden 
Unterschritt enthalt: is 

Aufzeichnen von Informationen, die das 
Vorhandensein des Management-Clients iden- 
tifizieren, in einer Datenstruktur des Anzeige- 
servers; 

Bestimmen (920), ob die Graphikoperationsan- 20 
forderung die Leistung von Fenstermanage- 
mentfunktionen erfordert; 
Ausgeben (940) der Graphikoperationsanfor- 
derung an den Management-Client (540), falls 
die Graphikoperationsanforderung die Lei- 25 
stung von Fenstermangementfunktionen erfor- 
dert; 

Ubersetzen (1050-1095) der die Leistung von 
Fenstermanagementfunktionen erfordernden 
Graphikoperationsanforderung in einen Satz 30 
von Graphikoperationsanforderungen mit ei- 
nem zweiten Format, das von einem zweiten, 
unterschiedlichen Anzeigeserver (510) ver- 
wendet werden kann ; durch den Management- 
Client (540); und 35 
direktes Ausfuhren (930) von Funktionen in der 
Graphikoperationsanforderung, welche keine 
Fenstermanagementfunktionen erfordern. 

2. Verfahren nach Anspruch 1 , bei dem der Schritt des 40 
Emulierens des Management-Clients (540) den fol- 
genden Unterschritt enthalt: 

Erzeugen einer Benutzerschnittstelle fur eine 
Anzeige, wobei die Benutzerschnittstelle ein Er- 
scheinungsbild und Steuerfunktionen fur jeden der 45 
Clients schafft. 

3. Verfahren nach Anspruch 2, bei dem das Verfahren 
ferner den folgenden Schritt enthalt: 

Senden von Nachrichten vom Anzeigeserver so 
(530) zum zweiten Server (510), urn mit der Anzeige 
(520) in Kommunikation zu treten. 

4. Verfahren nach Anspruch 3, bei dem der zweite 
Server (510) Nachrichten an den Anzeigeserver 55 
(530) sendet und der zweite Server eine Schnittstel- 
le mit Benuzterschnittstellen-Objekten enthalt, wo- 
bei der Unterschritt des Erzeugens der Benutzer- 



schnittstelle den folgenden Unterschritt enthalt: 

Empfangen einer Nach richt vom zweiten Ser- 
ver, wenn ein Benutzer eines der Benutzerschnitt- 
stellen-Objekte wahlt. 

5. Verfahren nach Anspruch 2, bei dem das Verfahren 
ferner den folgenden Schritt enthalt: 

Senden von Nachrichten vom Anzeigeserver 
an eine Schnittstelle zur Anzeige. 

6. Verfahren nach Anspruch 1, bei dem die Graphik- 
operationsanforderungen Anforderungen (1000) 
zur Erzeugung eines Fensters enthalten, wobei der 
Ausfuhrungsschritt den folgenden Unterschritt ent- 
halt: 

Verarbeiten einer Anforderung, um ein Fen- 
ster zu erzeugen, in dem eine Nachricht an den 
zweiten Server (510) gesendet wird, um wenig- 
stens ein Fenster zu erzeugen (1060). 

7. Verfahren nach Anspruch 1 , bei dem das Verfahren 
ferner die folgenden Schritte enthalt: 

Empfangen einer Nachricht vom zweiten Ser- 
ver (510); 

Ubersetzen (1500) der empfangenen Nach- 
richt in einem Satz von Anzeigeserver-Nach- 
richten; 

Bestimmen eines entsprechenden Satzes von 
Clients (533, 538), die den Satz von Anzeige- 
server-Nachrichten empfangen sollen; und 
Ausgeben des Satzes von Anzeigeserver- 
Nachrichten an den entsprechenden Satz von 
Clients. 

8. Verfahren nach Anspruch 7, bei dem der Schritt des 
Ausgebens der Graphikoperationsanforderung an 
den Management-Client (540) die folgenden Unter- 
schritte enthalt: 

Ubersetzen einer ausgewahlten der Anzeige- 
server-Nachrichten in dem vom Anzeigeserver 
empfangenen Satz von Anzeigeserver-Nach- 
richten in einen Satz von Nachrichten: 
Bestimmen eines entsprechenden Satzes von 
Clients (533, 538), die den Satz von Nachrich- 
ten empfangen sollen: und 
Ausgeben des Satzes von Nachrichten an den 
entsprechenden Satz von Clients. 

9. Verfahren nach Anspruch 7, bei dem der Unter- 
schritt des Ausgebens des Satzes von Anzeigeser- 
ver-Nachrichten an den entsprechenden Satz von 
Clients (533, 538) den folgenden Unterschritt ent- 
halt: 

Bestimmen, ob einer der Clients im Satz von 
Clients der emulierte Management-Client ist; 
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und 

Ausfuhren eines Satzes von Computerbefeh- 
len ; urn den Management-Client zu emulieren, 
falls einer der Clients in dem Satz von Clients 
der emulierte Managment-Client ist. s 

10. Computersystem, mit: 

einer Anzeige (520); 

einer Clientprozessor-Einrichtung (533, 538) 10 
zur Ausfuhrung von Clients; und 
einer Serverprozessor-Einrichtung (530), die 
an die Anzeige und an die Clientprozessor-Ein- 
richtung angeschlossen ist, um auf von den Cli- 
ents erzeugte Graphikoperationsanforderun- is 
gen zu antworten, wobei die Graphikoperati- 
onsanforderungen ein Format besitzen, das 
von der Serverprozessor-Einrichtung (530) 
verwendet werden kann, wobei die Serverpro- 
zessor-Einrichtung enthalt: 20 
eine Einrichtung (540) zum Emulieren eines 
Management-Clients (510), der Graphikmana- 
gementfunktionen fur die Clients schafft; 
eine Datenstruktur zum Aufzeichnen von Infor- 
mationen, die das Vorhandensein mehrerer Cli- 25 
ents einschlieBlich des Management-Clients 
identifizieren: 

eine Einrichtung (530) zum Empfangen der 
Graphikoperationsanforderung von den Clients 
(533, 538); 30 
eine Einrichtung, die an die Empfangseinrich- 
tung angeschlossen ist, um zu bestimmen, ob 
die Graphikoperationsanforderungen ein Fen- 
stermanagement erfordern; 
eine Einrichtung, die an die Empfangseinrich- 35 
tung und an die Bestimmungseinrichtung ange- 
schlossen ist, um die Graphikoperationsanfor- 
derungen, die kein Fenstermanagement erfor- 
dern, direkt auszufuhren; 

eine Einrichtung, die an die Empfangseinrich- 40 
tung und an die Bestimmungseinrichtung ange- 
schlossen ist, um an den emulierten Manage- 
ment-Client die Graphikoperationsanforderun- 
gen auszugeben, die ein Fenstermanagement 
erfordern; und 45 
eine Einrichtung ; die an den emulierten Mana- 
gement-Client angeschlossen ist, um die Gra- 
phikoperationsanforderungen, die ein Fenster- 
management erfordern, in entsprechende Sat- 
ze von Graphikanforderungen zu ubersetzen, so 
die ein zweites Format besitzen, die von einer 
zweiten, anderen Serverprozessor-Einrichtung 
verwendet werden konnen. 

11. System nach Anspruch 10, bei dem der emulierte 55 
Management-Client (510) enthalt: 

eine Einrichtung zum Ausgeben der entspre- 
chenden Satze von Graphikanforderungen an die 
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Serverprozessor-Einrichtung (530). 

12. System nach Anspruch 11 , bei dem die Einrichtung 
(540) zum Emulieren des Management-Clients ent- 
halt: 

eine Einrichtung zum Erzeugen einer Benut- 
zerschnittstelle auf der Anzeige, wobei die Benut- 
zerschnittstelle ein gleichmaftiges Erscheinungs- 
bild und Steuerfunktionen fur jeden der Clients 
schafft. 

13. System nach Anspruch 12, ferner mit einem weite- 
ren Server (510), der an die Serverprozessor-Ein- 
richtung (530) und an die Anzeige (520) ange- 
schlossen ist, wobei der andere Server enthalt: 

eine Einrichtung zum Verarbeiten der Graphik- 
operationsanforderungen mit dem zweiten For- 
mat; und 

wobei die Serverprozessor-Einrichtung (530) 
enthalt: 

eine Einrichtung zum Senden von Nachrichten 
an den anderen Server, um mit der Anzeige in 
Kommunikation zu treten. 

14. System nach Anspruch 13, bei dem der andere Ser- 
ver (510) eine Einrichtung fur die Schaffung von 
Fenstermanagementfunktionen enthalt. 

15. System nach Anspruch 14, bei dem der andere Ser- 
ver (510) enthalt: 

eine Einrichtung zum Senden von Nachrichten 
an den Anzeigeserver (530); und 
eine Einrichtung zum Erzeugen von Benutzer- 
schnittstellen-Objekten zum Manipulieren des 
Fensterstatus ; wobei die Einrichtung zum Er- 
zeugen der Benutzerschnittstelle enthalt: 
eine Einrichtung zum Empfangen einer Nach- 
richt vom anderen Server, wenn ein Benutzer 
eines der Benuzterschnittstellen-Objekte mani- 
puliert. 

16. System nach Anspruch 1 3, bei dem Anforderungen 
fur Graphikoperationen, die von Clients erzeugt 
werden, Anforderungen zur Erzeugung eines Fen- 
sters enthalten, wobei der andere Server eine Ein- 
richtung zum Erzeugen von Fenstern enthalt, die 
auf der Anzeige erscheinen konnen, wobei die Ein- 
richtung zum Erzeugen der Benutzerschnittstelle 
enthalt: 

eine Einrichtung zum Antworten auf eine An- 
forderung zum Erzeugen eines Fensters durch 
Senden einer Nachricht an den anderen Server um 
ein Fenster zu Erzeugen. 

17. System nach Anspruch 12, ferner mit einem weite- 
ren Server zum Erzeugen einer Benutzerschnitt- 
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stelle, wobei der andere Server enthalt: 

eine Einrichtung zum Senden von Anforde- 
rungen an die andere Serverprozessor-Einrich- 
tung, urn mit der Anzeige in Kommunikation zu tre- 
ten. s 

18. System nach Anspruch 12, ferner mit: 

einer Schnittstelle zur Anzeige; und 

einem weiteren Server, der enthalt: 10 

eine Einrichtung zum Senden von Nachrichten 

an die Schnittstelle zur Anzeige; und 

wobei die Serverprozessor-Einrichtung enthalt: 

eine Einrichtung zum Senden von Nachrichten 

an die Schnittstelle zur Anzeige. is 



einrichtung enthalt: 

eine Einrichtung zum Empfangen einer Anzei- 
geserver-Nachricht von der Einrichtung zum 
Ausgeben des Satzes von Anzeigeserver- 
Nachrichten; 

eine Einrichtung, die an die Empfangseinrich- 
tung angeschlossen ist, um die empfangene 
Anzeigeserver-Nachricht in einen Satz von 
Nachrichten zu ubersetzen: und 
eine Einrichtung, die an die Ubersetzungsein- 
richtung angeschlossen ist, um einen Satz der 
Clients zu bestimmen, die den Satz von Nach- 
richten, die von der Ubersetzungseinrichtung 
erzeugt werden, empfangen sollen. 



19. System nach Anspruch 10, bei dem die Einrichtung 
(540) zum Emulieren enthalt: 

einen ersten Satz von Computerbefehlen in ei- 20 

nem ersten Adressenraum; 

wobei die Einrichtung zum Ausfuhren der Gra- 

phikoperationsanforderung direkt enthalt: 

einen zweiten Satz von Computerbefehlen im 

ersten Adressenraum. 25 



23. System nach Anspruch 21 , bei dem die Einrichtung 
zum Ausgeben des Satzes von Nachrichten an den 
Satz von Clients enthalt: 

eine Einrichtung zum Bestimmen, ob einer 
der Clients im Satz ihrer Clients der Management- 
Client ist. 



Revendications 



20. System nach Anspruch 10, bei dem die Einrichtung 
(540) zum Emulieren des Management-Clients ent- 
halt: 

30 

einen ersten Satz von Computerbefehlen in ei- 
nem ersten Adressenraum; 
wobei die Einrichtung zum Ausfuhren der Gra- 
phikoperationsanforderung direkt enthalt: 
einen zweiten Satz von Computerbefehlen in 35 
einem vom ersten Adressenraum verschiede- 
nen Adressenraum. 

21. System nach Anspruch 10, ferner mit: 

40 

einem weiteren Server, wobei der andere Ser- 
ver enthalt: 

eine Einrichtung zum Erzeugen von Nachrich- 
ten; 

wobei die Serverprozessor-Einrichtung enthalt: 45 
eine Einrichtung zum Empfangen von Nach- 
richten vom anderen Server; und 
eine Einrichtung zum Ubersetzen einer emp- 
fangenen Nachricht in einen entsprechenden 
Satz von Anzeigeserver-Nachrichten; so 
eine Einrichtung zum Bestimmen eines Satzes 
von Clients, um den Satz von Anzeigeserver- 
Nachrichten zu empfangen; und 
eine Einrichtung zum Ausgeben des Satzes 
von Anzeigeserver-Nachrichten an den Satz 55 
von Clients. 

22. System nach Anspruch 21 . bei dem die Emulations- 



1 . Procede de realisation d'une interface de f enetrage 
uniforme comportant les etapes, executees par un 
serveur d'affichage (530), consistant: 

a emuler, dans le serveur d'affichage, un client 
de gestion (540) qui fournit des fonctions de 
gestion de visualisation graphique a destina- 
tion d'une multiplicity de clients (533, 538), 
I'etape d'emulation de client de gestion com- 
prenant la sous-etape consistant; 

a enregistrer, dans une structure de don- 
nees dudit serveur d'affichage, des informa- 
tions indiquant que le client de gestion existe; 
a determiner (920) si la demande d'operations 
de visualisation graphique exige I'execution de 
fonctions de gestion de fenetres; 
a soumettre (940) la demande d'operations de 
visualisation graphique au client de gestion 
(540) si la demande d'operations de visualisa- 
tion graphique exige I'execution de fonctions de 
gestion de fenetres; 

a traduire (1050-1095), par I'intermediaire du 
client de gestion (540), la demande d'opera- 
tions de visualisation graphique exigeant I'exe- 
cution de fonctions de gestion de fenetres en 
un ensemble de demandes d'operations de vi- 
sualisation graphique ayant un second format 
approprie a I'utilisation par un second serveur 
d'affichage, qui est different, (510); et 
a executer (930) directement des fonctions 
dans la demande d'operations de visualisation 
graphique qui n'exigent pas de fonctions de 
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gestion de fenetres. 

2. Procede selon la revendication 1 , dans lequel I'eta- 
pe d'emulation du client de gestion (540) comprend 
la sous-etape consistant: 

a generer une interface d'utilisateur pour un 
affichage, ladite interface d'utilisateur fournissant 
un aspect et des fonctions de commande pour cha- 
cun des clients. 

3. Procede selon la revendication 2, dans lequel le 
procede comprend, en outre, I'etape consistant: 

a envoyer des messages depuis le serveur 
d'affichage (530) au second serveur (510) pour 
communiquer avec I'affichage (520). 

4. Procede selon la revendication 3, dans lequel le se- 
cond serveur (510) envoie des messages au ser- 
veur d'affichage (530), et le second serveur com- 
prend une interface comportant des objets d'inter- 
face d'utilisateur, dans lequel la sous-etape de ge- 
neration de I'interface d'utilisateur comprend la 
sous-etape consistant: 

a recevoir un message en provenance du se- 
cond serveur lorsqu'un utilisateur selectionne I'un 
des objets d'interface d'utilisateur. 

5. Procede selon la revendication 2, dans lequel le 
procede comprend, en outre, I'etape consistant: 

a envoyer des messages depuis le serveur 
d'affichage a une interface donnant acces a I'affi- 
chage. 

6. Procede selon la revendication 1 , dans lequel les 
demandes d'operations de visualisation graphique 
comprennent des demandes (1000) de creation 
d'une fenetre, dans lequel I'etape d'execution com- 
prend la sous-etape consistant: 

a traiter une demande de creation de fenetre 
en envoyant au second serveur (510) un message 
demandant la creation (1060) d'au moins une fene- 
tre. 

7. Procede selon la revendication 1, dans lequel le 
procede comprend, en outre, les etapes consistant: 

a recevoir un message en provenance du se- 
cond serveur (510); 

a traduire (1500) le message recu en un en- 
semble de messages de serveur d'affichage; 
a determiner un ensemble correspondant de 
clients (533, 538) pour la reception de I'ensem- 
ble de messages de serveur d'affichage; et 
a soumettre I'ensemble de messages de ser- 
veur d'affichage a I'ensemble correspondant de 
clients. 

8. Procede selon la revendication 7, dans lequel I'eta- 



pe de soumission de demande d'operations de vi- 
sualisation graphique au client de gestion (540) 
comprend les sous-etapes consistant: 

5 a traduire un message selectionne parmi les 

messages de serveur d'affichage de I'ensem- 
ble de messages de serveur d'affichage recus 
en provenance du serveur d'affichage en un en- 
semble de messages; 

70 a determiner un ensemble correspondant de 

clients (533, 538) pour la reception de I'ensem- 
ble de messages; et 

a soumettre I'ensemble de messages a I'en- 
semble correspondant de clients. 

15 

9. Procede selon la revendication 7, dans lequel la 
sous-etape de soumission de I'ensemble de mes- 
sages de serveur d'affichage a I'ensemble corres- 
pondant de clients (533, 538) comprend la sous- 

20 etape consistant: 

a determiner si un des clients de I'ensemble de 
clients est le client de gestion emule; et 
aexecuterun ensemble destructions machine 
25 pour emuler le client de gestion si un des clients 

de I'ensemble de clients est le client de gestion 
emule. 

10. Systeme informatique comprenant: 

30 

un affichage (520); 

un moyen formant processeur de clients (533, 

538) pour executer les clients; et 

un moyen formant processeur de serveur 

35 (530), couple a I'affichage et au moyen formant 

processeur de clients, pour reagir a des de- 
mandes d'operations de visualisation graphi- 
que generees par lesdits clients, lesdites de- 
mandes d'operations de visualisation graphi- 

40 que ayant un format approprie a I'utilisation par 

ledit moyen formant processeur de serveur 
(530), le moyen formant processeur de serveur 
comprenant: 

un moyen (540) pour emuler un client de ges- 
45 tion (510) qui fournit des fonctions de gestion 

de visualisation graphique a destination des 
clients; 

une structure de donnees pour enregistrer des 
informations indiquant qu'il existe une multipli- 
ed cite de clients comprenant le client de gestion; 

un moyen (530) pour recevoir les demandes 
d'operations de visualisation graphique ema- 
nant des clients (533, 538); 
un moyen, couple au moyen de reception, pour 
55 determiner si les demandes d'operations de vi- 

sualisation graphique exigent une gestion de 
fenetres; 

un moyen, couple au moyen de reception et au 
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moyen de determination, pour executer direc- 
tement les demandes d'operations de visuali- 
sation graphique qui n'exigent pas de gestion 
de fenetres; 

un moyen, couple au moyen de reception et au 
moyen de determination, pour soumettre au 
client de gestion emule les demandes d'opera- 
tions de visualisation graphique qui necessi- 
tent, effectivement, une gestion de fenetres; et 
un moyen, couple audit client de gestion emule, 
pour traduire lesdites demandes d'operations 
de visualisation graphique qui exigent, effecti- 
vement, une gestion de fenetres en des ensem- 
bles correspondants de demandes de visuali- 
sation graphique ayant un second format ap- 
proprie a I'utilisation avec un second moyen, 
different, formant processeur de serveur. 

11. Systeme selon la revendication 10, dans lequel, le 
client de gestion emule (510) comprend: 

un moyen pour soumettre les ensembles cor- 
respondants de demandes d'operations de visuali- 
sation graphique au moyen formant processeur de 
serveur (530). 

12. Systeme selon la revendication 11, dans lequel le 
moyen (540) pour emuler le client de gestion com- 
prend: 

un moyen pour generer une interface d'utili- 
sateur sur I'affichage, ladite interface d'utilisateur 
fournissant un aspect uniforme et des fonctions de 
commande a destination de chacun des clients. 

13. Systeme selon la revendication 12, comportant, en 
outre, un autre serveur (510) ; couple au moyen for- 
mant processeur de serveur (530) et a I'affichage 
(520), dans lequel ledit autre serveur comprenant: 

un moyen pour traiter lesdites demandes 
d'operations de visualisation graphique ayant 
ledit second format; et 

dans lequel le moyen formant processeur de 
serveur (530) comprend: 

un moyen pour envoyer a I'autre serveur 
des messages pour communiquer avec I'affi- 
chage. 

14. Systeme selon la revendication 13, dans lequel 
I'autre serveur (510) comprend un moyen pourfour- 
nir des fonctions de gestion de fenetres. 

15. Systeme selon la revendication 14, dans lequel 
I'autre serveur (510) comprend: 

un moyen pour envoyer des messages au ser- 
veur d'affichage (530); et 
un moyen pour generer des objets d'interface 
d'utilisateur pour manipuler I'etat des fenetres, 



dans lequel le moyen pour generer I'interface 
d'utilisateur comprend: 

un moyen pour recevoir un message en 
provenance de I'autre serveur lorsqu'un utilisa- 
5 teur manipule un des objets d'interface d'utili- 

sateur. 

16. Systeme selon la revendication 13, dans lequel les 
demandes d'operations de visualisation graphique 
70 generees par des clients comprennent des deman- 
de de creation d'une fenetre, et I'autre serveur com- 
prend un moyen pour creer des fenetres qui peu- 
vent apparaTtre sur I'affichage, dans lequel le 
moyen pour generer I'interface d'utilisateur corn- 
's prend: 

un moyen pour reagir a une demande de 
creation d'une fenetre en envoyant un message a 
I'autre serveur demandant la creation d'une fenetre. 

20 17. Systeme selon la revendication 12, comportant, en 
outre, un autre serveur pour generer une interface 
d'utilisateur, I'autre serveur comprenant: 

un moyen pour envoyer des demandes au 
moyen formant processeur de serveur pour com- 

25 muniquer avec I'affichage. 

18. Systeme selon la revendication 12, comportant, en 
outre: 

une interface donnant acces a I'affichage; et 
30 un autre serveur comprenant: 

un moyen pour envoyer des messages a I'in- 
terface donnant acces a I'affichage: et 
dans lequel le moyen formant processeur de 
35 serveur comprend: 

un moyen pour envoyer des messages a 
I'interface donnant acces a I'affichage. 

19. Systeme selon la revendication 10, dans lequel le 
40 moyen (540) d'emulation comprend: 

un premier ensemble d'instructions machine 

dans un premier espace adresses; 

et 

45 dans lequel le moyen pour executer la deman- 

de d'operations de visualisation graphique 
comprend directement: 

un second ensemble d'instructions ma- 
chine dans le premier espace adresses. 

50 

20. Systeme selon la revendication 10, dans lequel le 
moyen (540) pour emuler le client de gestion com- 
prend: 

55 un premier ensemble d'instructions machine 

dans un premier espace adresses; 
dans lequel le moyen pour executer la deman- 
de d'operations de visualisation graphique 



35 



50 

20. 
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comprend directement: 

un second ensemble destructions machine 
dans un espace adresses different du premier 
espace adresses. 

5 

21. Systeme selon la revendication 10, comportant, en 
outre: 

un autre serveur, I'autre serveur comprenant: 

un moyen pour generer des messages; 10 
dans lequel le moyen formant processeur de 
serveur comprend: 

un moyen pour recevoir des messages en 
provenance de I'autre serveur; is 
et 

un moyen pour traduire un message regu 
en un ensemble correspondant de messa- 
ges de serveur d'affichage; 
un moyen pour determiner un ensemble de 20 
clients pour la reception de I'ensemble de 
messages de serveur d'affichage; et 
un moyen pour soumettre I'ensemble de 
messages de serveur d'affichage a I'en- 
semble de clients. 25 

22. Systeme selon la revendication 21, dans lequel le 
moyen d'emulation comprend: 

un moyen pour recevoir un message de ser- 30 
veur d'affichage en provenance du moyen pour 
soumettre I'ensemble de messages de serveur 
d'affichage; 

un moyen, couple au moyen de reception, pour 
traduire le message de serveur d'affichage regu 35 
en un ensemble de messages; et 
un moyen, couple au moyen de traduction, pour 
determiner un ensemble de clients pour la re- 
ception de I'ensemble de messages produits 
par le moyen de traduction. 40 

23. Systeme selon la revendication 21, dans lequel le 
moyen pour soumettre I'ensemble de messages a 
I'ensemble de clients comprend: 

un moyen pour determiner si un des clients 45 
de I'ensemble de ses clients est le client de gestion. 



50 



55 



19 



EP 0 469 709 B1 



100 



7 



L 



110 



X CLIENT 



I 



120 



X CLIENT 



X SERVER 




130 

X CLIENT 
(WINDOW 
MANAGER) 



j 140 





FIG. 1 

PRIOR ART 



GRAPHICS 
HARDWARE 
150 



300 



310 



HOST CLIENT 



-320 



HOST CLIENT 



330 



HOST CLIENT 



HOST SERVER 
FRONT END AND 
SUPPORT FUNCTIONS 



^340 




GRAPHICS 
HARDWARE 



FIG. 3 

PRIOR ART 



20 



EP 0 469 709 B1 




EP 0 469 709 B1 




22 



EP 0 469 709 B1 



CD 




WINDOW 
MANAGER 
(WMCLIENT) 


cr 


HOST 
CLIENT 


(X SERVE 



o 

CO 





I— 


CM 




LO 


LU 




I 




O 




ST 




o 








LO 
LO 

in 



LOj 



23 



EP 0 469 709 B1 




24 



EP 0 469 709 B1 



o 



Q_ 

O 



CO 
CD 
CD 

ca 

CO 
CO 
CD 



CD 

> 
o 



-a 
cz 
ca 

CD 



"co 



id o 



1_ ° 



_CD 



CD 
"O 

-o 
<: 



.E ^ .-9 "g 

co -— co — 

^ ^ . ^ CO 



i— (X> o o 

O $ CD CO i 

-K OS g E 

CD ^ c: o 

O X X ' ~ 

cz <d 
co cz 









CL 




ca 




E 


c: 


X 


CD 




ca 




o_ 




c> 


X 






CD 




> 


CD*" 




> 


To 




a> 


"co 




CD 


a 


cc 


o 






CD 


CO 


cz 


o 


O 


Ol 


-ZL 




«^ 



ra 

CL 
CO 

co 

CD 

E 

CO 
CO 

CD 
CO 

CD 



CO 

CO 
CO 

CD -s- CO 

Q-_g- co 

55 Z3 CL. 

E o 2 

CO 

CD -E o 
GO O 

o -o E 

§75-8 
ra S.E 



oi 

o 



~~ CD 

CL CZ — CO 

n CD _2 CD CD 

< _cf m . - - - ^2 "cd~ ^ co co" 



-^^li *3 ill i ^-llif ll^^-Itl 

, frt ,— -"r rr\ -CZ _r- »sj • - n\ n\ ~ jtt» m r - rr» »— CO »_ CD ^ n 



HIT) CL CZ CL^= i5 £ _Q 0_0-DCD-0_QO-0_OOJ^ ^ O > E Z1>X3* 

o 

"O 

cz 

1 CD CD _F ^ CD 

DC^^^^^cjcjcTco °- cc 

o ^^^^^t^^^^-E^ czcz^-o^^^-o^^-o^^^g^ 

•rr Occoooooo^^n^ _ := o cz c c: cz c= c: cz c: c= c= c: i= ^2 

Z CD$T3T:*0 _ OTJ--.-[i: CD^ J=r _Er "O 0)0)0)0)0)0)0)010)01 CD__3 . E 

^5 ^ "co co .E .E .— .E .E 5? "55 co ca x x -E 'oo -co 'co *co 'co *co go £75 'go 'co ^ j> § 

-S ^ cz ^>>r^-^b^^^J$ ^^^ — — -^ cz cz cz cz cz cz cz cz cz cz cz a? 

CL 



CZ> O 
CO CM 



25 



EP 0 469 709 B1 



800^ 

X WINDOW TREE PM WINDOW TREE 



hpMWNd 
HASBEENMAPPED 



FIRSTCHILD 



hpMWNd 
HASBEENMAPPED 



FIRSTCHILD 



hpMWNd 
HASBEENMAPPED 



FIRSTCHILD 





> 












J 


STANDARD 
> WINDOWREC 
IDENTIFIERS 






> 


. r 803 




r 804 








> 


















. r 805 




r 806 








> 















I STANDARD 
I PM WINDOW 
f DATA 
J STRUCTURE 



FIG. 8 



26 



EP 0 469 709 B1 



900 



910^ 



RECEIVE CLIENT 
REQUEST 



920^ 

" DOES 
REQUEST REQUIRE MANAGE> 
MENT ? 



940^ 



JES 



930- 



NO 



EXECUTE REQUEST 



SUBMIT REQUEST 
TO EMULATED 
MANAGER 



FIG. 9 



CREATE 
X WINDOW AS 
PARENT 



1100 



1110 



ALLOCATE WINDOWREC 



1120 



1130 a 



INITIALIZE WINDOWREC 



REMOVE FROM SIBLING CHAIN 



1140 n 



INSERT WMCLIENT WINDOW AS CHILD OF ROOT AND 
REQUESTED WINDOW AS CHILD OF WMCLIENT WINDOW 



1150 a 



UPDATE PM WINDOW STATUS 



1160 n 



UPDATE X WINDOW STATUS 



11 70 -) 



CALL ADDRESOURCE FOR WINDOW 



11 80 -) 



GENERATE REPARENT NOTIFY EVENT 



I 

FIG. 11 



27 



EP 0 469 709 B1 



1000 



1020-) 



TRANSLATE X 
COORDINATES 

TO PM 
COORDINATES 



1025-1 



CREATE PLAIN 
PM WINDOW 



10301 



SAVE POINTER 
TO WINDOWREC 
IN PMREC 



1035-) 



SAVE POINTER 
TO PMREC IN 
WINDOWREC 



1040 i 



GENERATE 
CREATENOTIFY 
EVENT 



1010 



CREATEWINDOW REQUEST 



ALLOCATE X 
WINDOWREC 



YES 




r 



YES 



1050i 



CALCULATE 
PARENT ORIGIN 



1055i 



CALCULATE 
PM ORIGIN 



10601 



CREATE 2 PM 
WINDOWS 



UPDATE PM 
WINDOW 
STATUS 



10801 



SAVE POINTER 
TO PMREC IN 
WINDOWREC 



10901 



GENERATE 
CREATENOTIFY 
EVENT 



1095i 



CREATE X 
WINDOW AS 
PARENT 



I 



FIG. 10 



28 



EP 0 469 709 B1 



(3 < 



QOCL 

UJ LU => 
( nOQCL 

its 

•j ^ LU 

002: a. § 

<C — LU O 



goo 

LULU^LU 
£^LU^ 

Sj^LU^ 
CCO^O 

rn Q ° 



CM 



go 




1- LU 




EATE ' 




^ CC 




— > 

r 


'ARE 
HII D 

MILL-/ 


— ► 




0 


LU ^ 




O Q- 


CM 


CC 


CM 




Q O 
LUZQ 

— r_ ^ oq 

> 1 — LU 

cc^ ^ a. 
luJ^lu^ 

OS 



o 
o 

CM 



LU^LU^ 
00 LU CQ LU 
oJ CC ^ CL ^ 
LULLJOIDO 

<C O LU O LU 
O-JDQCLCQ 



CO 

<: 
o 



O 


O 


1— 


1— 


Q 


O 


LU 


LU 


1 — 


h~ 




-Z- 
LU 


LU 

DC 


CC 


< 


cc< 


n_ 


O O- 


UJ 


LU 


DC 


CL. DC 






<D 


So 


2: 


0^ 


LU 


0- LU 


CO 


LU m 


DC 


^cc 


UJ 


O^ 




0 5 


O 


LU O 


l 





o 

I — 

Q 
UJ 



UJ 
DC 

cc°=g 

OQ]< 

— 1 CD LU 

hOuj 

co cl m 






35 












1— LU 






ZZ. DC 




— > 


LU O 


> 




DC — l 




r 


<S 


r 




LU ^ 


00 


0 




CM 


DC 


CM 











CM 

■r— 



29 



1 300 



1302-) 

GET CURRENT 
WINDOW WIDTH 
AND HEIGHT 



13031 

CALCULATE 
NEW WINDOW 
WIDTH AND 
HEIGHT 



1304-) 

CALCULATE 
NEW WINDOW 
ORIGIN 



13051 

SET NEW 
WINDOW WIDTH, 
HEIGHT, AND ORIGIN 



EP O 469 709 B1 



1306i 

GET CURRENT 
BORDER WIDTH 
AND HEIGHT 



1307i 

CALCULATE 
NEW WINDOW 
WIDTH AND 
HEIGHT 



13081 

SET NEW 
WINDOW WIDTH 
AND HEIGHT 




FIG. 13 



30 



EP 0 469 709 B1 




1430^ 

CALCULATE 
NEW WINDOW 
PM COORDINATES 



1440^ 

SET NEW 
POSITION IN PM 
COORDINATES 



FIG. 14 



31 



EP 0 469 709 B1 



1500 



1501 - 



GET POINTER TO X 
WINDOWREC OF 
MOVED WINDOW 




.WW. j 

GET P 

AND PC 
OF P/ 
WIN 


M SIZE 

)sition 

IRENT 
DOW 


1505i 




SET NEW 
COORDINATES IN 
PARENT WINDOW 



15061 



GET PM 
COORDINATES 
OF MOVED 
WINDOW 



1507i 



CALCULATE 
NEW X WINDOW 
COORDINATES 



1508 1 




SET NEW 
COORDINATES 
IN X WINDOWREC 



15101 „ 



GENERATE 
CONFIGURE- 
NOTIFY EVENT 



1511 i 



CHANGE 
WINDOW 
COORDINATES 



FIG. 15 



32 



EP 0 469 709 B1 



1 600 



16051 

GET POINTER TO 
X WINDOWREC 



1610 ^ 



DETERMINE 
WHETHER MINIMIZE 
OR RESTORE 



USER HAS 
MINIMIZED 
WINDOW 



USER HAS 
RESTORED 
WINDOW 




SEND UNMAPWINDOW 
REQUEST FOR FRAME 
AND MANAGED 
WINDOWS 



SEND MAPWINDOW 
REQUEST FOR FRAME 
AND MANAGED 
WINDOWS 



FIG. 16 



33 



EP 0 469 709 B1 



1700 -\ 



1701 



GET POINTER TO X 


WINDOWREC 


1702i 






UPDATE INPUT 






STATUS 





1704 




DESIGNATE ROOT 

WINDOW AS 
REVERT WINDOW 




DESIGNATE 
WMCLIENT 
WINDOW AS 
REVERT WINDOW 

1706i | 

MOVE WMCLIENT 
WINDOW TO 
TOP OF 
STACKING ORDER 



FIG. 17 



34 



